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REMARKS 



Claims 1-25 were pending in the Application. Claims 1-25 were rejected under 
35 U.S.C. §103(a). Applicants respectfully traverse the rejections and respectfully 
request that the Examiner reconsider and withdraw all outstanding rejections. 

I. REJECTIONS UNDER 35 U.S.C. SlOBfaV 

The Office Action has rejected claims 1-25 as being unpatentable over San 
Andres et al. (U.S. Patent No. 5,956,489) (hereinafter "San Andres"). Applicants 
respectfully traverse the rejections and respectfully request that the Examiner reconsider 
and withdraw all outstanding rejections. 

A prima facie showing of obviousness requires the Examiner to establish, inter 
alia, that the prior art references teach or suggest, either alone or in combination, all of 
the limitations of the claimed invention, and the Examiner must provide a moti vation or 
suggestion to combine or modify the prior art reference to make the claimed inventions. 
See M.P.E.P. §2142. The motivation or suggestion to combine references must come 
from one of three possible sources: the nature of the problem to be solved, the teachings 
of the prior art, and the knowledge of persons of ordinary skill in the art. See In re 
Rouffet, 47 U.S.P.Q,2d 1453, 1458 (Fed. Cir. 1998). The showings must be clear and 
particular. See In re Dembiczak, 50 U.S.P.Q.2d 1614, 1617 (Fed. Cir. 1999). Broad 
conclusory statements regarding the teaching of multiple references, standing alone, are 
not evidence. See Id, 
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In order to reject under 35 U.S.C. §103, therefore, the Examiner must provide a 
proper motivation for combining or modifying the references. See M.P.E.P. §2 1 42; In re 
Rouffet,47U.S.?.Q.2d 1453, 1457-1458 (Fed. Cir. 1998). The Examiner recites that "it 
would have been obvious to a person of ordinary skill in the art at the time the invention 
was made to modify the teaching of San Andres with the step of each node in the 
computer cluster voting based on a functional outcome of the database update request. 
This modification would allow the teachings of San Andres to provide access to identical 
data and so that the on line service appears the same to all end users ^ See Office 
Action (dated July 3, 2001), Pages 3-4. The Examiner further recites as motivation that 
"San Andres provides user access to service content data that is updated by the on line 
service on a transaction by transaction basis, and permits users to read and download 
messages for review by other users, see col 1, lines 38-43." See Office Action (dated 
September 25, 2001), Page 2. 

There is no motivation to modify San Andres as there is no suggestion or 
motivation in San Andres or in the knowledge of those ordinary skilled in the art so thatl 
each application server votes based on a functional outcome of the database update 
request. As stated above, the Examiner points to providing users access to service 
content data that is updated by the on line service on a transaction by transaction basis 
and permitting users to read and download messages for review by other users as 
motivation for modifying San Andres. However, the Examiner's motivation for 
modifying San Andres so that users are able to read and download messages does not 
explain or imply that San Andres should be modified so that each application server 
votes based on a functional outcome of the database update request. Furthermore, San 
Andres teaches that "one problem with the two-phase commit protocol is that it is poorly 
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suited for an on-line services network that handles large numbers of concurrent user 
connections." See Column 2, Lines 13-15. San Andres farther teaches that "what is 
needed, therefore, is a mechanism for efficiently processing update requests made to 
replicated, transaction-based services y Column 2, Lines 20-22. San Andres farther 
teaches that "what is also needed is an efficient mechanism for bringing the content of an 
application server up-to-date with that of other application servers, so that new 
application servers can be added to service group ... and so that existing application 
servers can efficiently be taken off-line for maintenance'' See Column 2, Lines 23-30. 
As interpreted by the Applicants, the purpose of San Andres is to ensure that existing 
application servers can efficiently be taken off-line for maintenance which was a problem 
with the two-phase commit protocol. There would be no motivation to provide users 
access to service content data that is updated by the on line service on a transaction by 
transaction basis and permiting users to read and download messages for review by other 
users in San Andres as the purpose of San Andres is to ensure that existing application 
servers can efficiently be taken off-line for maintenance. Therefore, there is no 
motivation to modify San Andres as there is no suggestion or motivation in San Andres 
or in the knowledge of those ordinary skilled in the art to modify San Andres so that each 
application server votes based on a functional outcome of the database update request. 

As the Applicants have previously shown, there is no motivation to modify San 
Andres as the proposed modification would render the invention in San Andres 
unsatisfactory for its intended purpose and therefore there is no suggestion or motivation 
to make the proposed modification. See Reply under 37 C.F.R. §1.111, mailed July 1 9, 
200l,pages4-5; See In re Gordon, 733 F.2d900, 221 U.S.P.Q. 1125 (Fed. Cir. 1984); 
M.P.E.P. §2143.01 . The Examiner has not addressed this in the instant Office Action, 
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Paper No. 7. Where the Applicants traverse a rejection, the Examiner should answer the 
substance of Applicants ' argument if the Examiner repeats the rejection. See M.P.E.P. 
§707. 07(f). Furthermore, the proposed modification would change the principle of 
operation of San Andres and therefore the teachings of San Andres are not sufficient to 
render the claims prima facie obvious. See Reply under 37 C.F.R. §1.111, mailed July 
19, 2001, pages 4-5; See In reRatti, 270 F.2d 810, 123 U.S.P.Q. 349 (C.C.P.A. 1959); 
M.P.E.P. §2143.01 . The Examiner has not addressed this in the instant Office Action, 
Paper No. 7. Where the Applicants traverse a rejection, the Examiner should answer the 
substance of Applicants' argument if the Examiner repeats the rejection. See M.P.E.P. 
§707. 07 (f). San Andres teaches that "the servers 120 that receive the update transaction 
from the Arbiter respond by processing the update transaction, and by returning a status 
code that indicates the success or failure of the transaction." See Column 19, Lines 
25-28. San Andres further teaches that "the update transactions are dispatched to the 
servers 120 in a serialized order ...so that all servers of the service group process the 
update transactions in the same order. This ensures consistency between the replicated 
copies of the service content data. Each time an update transaction is dispatched by the 
Arbiter, the Arbiter monitors the outcome ("success" or "failure") of the transaction on 
each server 120 by checking the status codes retumed by the servers 120. When one 
server 120 of the service group processes the dispatched transaction differently than the 
other servers, the Arbiter uses a voting scheme to decide which server or servers are to 
be taken off-line within the service group. In the general case, the Arbiter uses a 
"majority rules" voting scheme. Under the majority rules scheme, if a minority number 
of servers 120 of the service group report a different outcome than the other servers, the 
minority servers are treated as being "inconsistent" with the final outcome, and are taken 
off-line." See Column 19, Lines 37-55. As interpreted by the Applicants, San Andres 
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teaches that an Arbiter may use a voting scheme to decide which application servers are 
deemed to be consistent and take application servers that are inconsistent off line for 
maintenance. In other words, the correct processing is determined to be that the majority 
have processed the transaction consistently and the minority have processed the 
transaction inconsistently. 

San Andres further teaches that "what is also needed is an efficient mechanism 
for bringing the content of an application server up-to-date with that of other application 
servers ...so that existing application servers can efficiently be taken offMne for 
maintenance'' See Column 2, Lines 23-30. As interpreted by the Applicants, the 
purpose of San Andres is to ensure that existing application servers can efficiently be 
taken off-line for maintenance. However, by having each application server implement 
a voting scheme to indicate whether there is a difference between the broadcast results 
and the local modification-result code, the Arbiter would not be able to decide which 
application servers are inconsistent and thus be taken off-line for maintenance. Hence, 
the proposed modification would render the invention in San Andres unsatisfactory for 
its intended purpose and therefore there is no suggestion or motivation to make the 
proposed modification. See In re Gordon, 733 F.2d 900, 221 U.S.P.Q. 1 125 (Fed. Cir. 
1984); M.P.E.P. §2143.01. Furthermore, the proposed modification would change the 
principle of operation of San Andres and therefore the teachings of San Andres are not 
sufficient to render the claims prima facie obvious as a matter of law. See In re Ratti, 
270 F.2d 810, 123 U.S.P.Q. 349 (C.C.P.A. 1959); M.P.E.P. §2143.01. 
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The Examiner contends that "it must be recognized that any judgment on 
obviousness is necessarily a reconstruction based upon hindsight reasoning. See In re 
McLaughlin, 433 F.2d 1392, 170 U.S.P.Q. 209 (C.C.P.A. 1971)." See Office Action, 
Page 3. However, the Examiner's reliance on In re McLaughlin is misplaced. In re 
McLaughlin does not relieve the Examiner of the Examiner's burden of demonstrating 
by objective evidence that the obviousness rejection takes into account only knowledge 
which was within the level of ordinary skill at the time the claimed invention was made 
and does not include knowledge gleaned from the Applicants' disclosure. Indeed, it is 
now well settled that it must be demonstrated by objective factual evidence that the 
obviousness rejection does not include knowledge gleaned only from the Applicants 
disclosure, and, for example, relying on the Applicants disclosure to find prior art 
corollaries of the claim limitations is an improper hindsight reconstruction. See In re 
i)ewfezczaA:175F.3d994,999,50U.S.P.Q.2d 1613, 1617(Fed.Cir. 1999); In re Rouffet, 
149 F.3d 1350, 1357, 47 U.S.P.Q.2d 1453,1457 (Fed. Cir. 1998). Moreover, broad 
conclusory statements regarding the teachings of multiple references, standing alone, are 
not evidence. See In re Dembiczak, 175 F.3d 994, 999, 50 U.S.P.Q.2d 1613, 1617; 
accord reKotzab, 111 F.3d 1365, 1370, 55 U.S.P.Q.2d 1313, 1317 (Fed. Cir. 2000); 
M.P.E.P. § 2143.01 (explaining//! reKotzab). 

San Andres does not teach or suggest ''each node in the computer cluster voting 
based on a functional outcome of the database update request as recited in claim 1 . San 
Andres does not teach or suggest ''voting, by all of the other nodes in the computer 
cluster^ to approve update if a match results from the comparison" as recited in claims 
9and21 and similarly claim 15. The Office Action (dated July 3, 2001) states that "San 
Andres does not explicitly indicate the step of each node in the computer cluster voting 
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based on a functional outcome of the database update request." See Office Action (dated 
July 3, 2001), Page 3. The Office Action (dated July 3, 2001 ) further states that "it would 
have been obvious to a person of ordinary skill in the art at the time the invention was 
made to modify the teaching of San Andres with the step of each node in the computer 
cluster voting based on a functional outcome of the database update request. This 
modification would allow the teachings of San Andres to provide access to identical data 
and so that the on line service appears the same to all end users'' See Office Action 
(dated July 3, 2001), Pages 3-4. For at least the reasons stated above. Applicants assert 
that it would not be obvious to modify the teachings of San Andres with the step of each 
node in the computer cluster voting based on a functional outcome of the database 
update request and therefore the Examiner has not presented a prima facie case of 
obviousness. Furthermore, for at least the reasons stated above, Applicants assert that 
it would not be obvious to modify the teachings of San Andres with the step of voting by 
all of the other nodes in the computer cluster and therefore the Examiner has not 
presented a prima facie case of obviousness. 

San Andres does not teach or suggest ''detecting an out-of-sync condition as a 
result of a different functional outcome" as recited in claim 1. Instead, San Andres 
teaches that "when one server 120 of the service group processes the dispatched 
transaction differently than the other servers, the Arbiter uses a voting scheme to decide 
which server or servers are to be taken off-line within the service group. In the general 
case, the Arbiter uses a "majority rules" voting scheme. Under the majority rules 
scheme, if a minority number of servers 120 of the service group report a different 
outcome than the other servers, the minority servers are treated as being ''inconsistent" 
with the final outcome, and are taken off-line." See Column 19, Lines 46-55. As 
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interpreted by the Applicants, San Andres teaches that an Arbiter may use a voting 
scheme to decide which application servers are deemed to be consistent and take 
application servers that are inconsistent off-line for maintenance. As interpreted by the 
Applicants, San Andres simply teaches an Arbiter using a scheme to determine which 
servers are to be taken off-line but does not teach detecting an out-of-sync condition as 
a result of a different functional outcome. 

San Andres does not teach or suggest ''applying the update to a local copy of the 
database at each of the pluraUty of nodes in the computer cluster" as recited in claims 9 
and 21 and similarly in claim 15. Instead, San Andres teaches that "the servers 120 that 
receive the update transaction from the Arbiter respond by processing the update 
transaction^ and by returning a status code that indicates the success or failure of the 
transaction'' See Column 19, Lines 25-28. San Andres further teaches that "all 
replicated servers of the service group maintain local copies of the servicers content 
data, and provide user access to such data." See Column 9, Lines 19-21 . As interpreted 
by the Applicants, San Andres teaches that the replicated servers maintain local copies 
of the service's content data. Furthermore, as interpreted by the Applicants, San Andres 
teaches that the servers process the update transaction received from the Arbiter. 
However, as interpreted by the Applicants, San Andres does not teach that the servers 
apply the update to a local copy of the database. San Andres simply teaches that the 
servers process the update transaction. Applicants kindly request the Examiner to 
particularly point out in San Andres where the servers apply the update to a local copy 
of the database. 
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San Andres does not teach or suggest that the ''node requesting update broadcasts 
results of update to all of the other nodes in the computer cluster'' as recited in claims 
9 and 21 and similarly in claim 15. Instead, San Andres teaches that "when an 
application server of a service group receives a client request that indicates a 
modification to replicated service content data, the server /service generates an update 
transaction and sends the update transaction to the Arbiter, The Arbiter records the 
update transaction in a service-group specific transaction log ... and forwards the 
transaction for inmiediate processing to every application server in the server group ... 
The application servers process the update transaction, and return status codes 
indicating, for each respective application server, the 'success' or 'failure' of the 
transaction," See Column 3, Lines 26-38. As interpreted by the Applicants, San Andres 
teaches that the server receiving the request that indicates a modification generates an 
update transaction and sends the update transaction to the Arbiter. As interpreted by the 
Applicants, San Andres further teaches that the Arbiter forwards the update transaction 
to each server and that each server returns a status code to the Arbiter indicating the 
success or failure of the transaction. San Andres does not teach that the node requesting 
an update broadcasts the results of the update to all of the other nodes in the computer 
cluster. 

San Andres does not teach or suggest "comparing^ by all of the other nodes in the 
computer cluster, the update results to results of application of the update to the local 
copy of the database" as recited in claims 9 and 21 and similarly in claim 15. Instead, 
San Andres teaches that "when one server 120 of the service group processes the 
dispatched transaction differently than the other servers, the Arbiter uses a voting scheme 
to decide which server or servers are to be taken off-line within the service group. In the 
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general case, the Arbiter uses a "majority rules" voting scheme. Under the majority rules 
scheme, if a minority number of servers 120 of the service group report a different 
outcome than the other servers, the minority servers are treated as being "inconsistent^ 
with the final outcome, and are taken off-line." See Column 19, Lines 46-55. As 
interpreted by the Applicants, San Andres teaches that an Arbiter may use a voting 
scheme to decide which application servers are deemed to be consistent and take 
application servers that are inconsistent off-line for maintenance. San Andres does not 
teach that all of the other nodes in the computer cluster compare the update results to 
results of apphcation of the update to the local copy of the database. Furthermore, San 
Andres does not teach that all of the other nodes in the computer cluster compare the 
update results to results of application of the update to the local copy of the database. 

San Andres does not teach or suggest ''voting, by all of the other nodes in the 
computer cluster^ to approve update if a match results from the comparison'' as recited 
in claims 9 and 21 and similarly in claim 15. San Andres teaches that "whenever the 
Arbiter replicates a transaction, the Arbiter monitors the outcome of the transaction on 
each server 120 of the service group to ensure consistent processing of the transaction 
by all such servers. When one or more servers 120 indicates a different outcome than 
the other servers of the service group, the Arbiter uses a voting scheme to resolve the 
conflict between the servers," See Column 17, Lines 10-17. The Office Action (dated 
September 25, 2001) states that the "Examiner is entitled to give claim limitations their 
broadest reasonable interpretation in light of the specification." See OfiBce Action (dated 
September 25, 2001), Page 4. Applicants respectfiiUy point out to the Examiner that the 
Examiner is entitled to give claim limitations their broadest reasonable interpretation in 
light of the specification. In particular, the Examiner may not simply ignore language 
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in the claims. All words in a claim must be considered in judging the patentability of 
that claim against the prior art. See In re Wilson, 424 F.2d 1382, 1385, 165 U.S.P.Q. 
494, 496 (C.C.P.A. 1970); M.P.E.P. §2143.03. As interpreted by the Applicants, San 
Andres teaches that an Arbiter may use a voting scheme to decide which application 
servers are deemed to be consistent and take application servers that are inconsistent ofF- 
Hne for maintenance. San Andres does not teach voting, by all of the other nodes in the 
computer cluster. Furthermore, San Andres does not teach voting, by all of the other 
nodes in the computer cluster, to approve update if a match results from the comparison. 

San Andres does not teach or suggest "a group services client operable for 
broadcasting an update to a database shared among a plurality of nodes in the computer 
cluster" as recited in claim 9. Instead, San Andres teaches a "host data center 104" that 
"comprises a plurality of application servers (APP servers) 120 connected to a high 
speed local area network (LAN) 122" See Column 5, Lines 18-20. Furtheraiore, San 
Andres teaches a '^host data center 104" that "includes multiple Arbiter microcomputers 
725thatrunthe Arbiter service application." 5ee Colunm 6, Lines 33-34. Furthermore, 
San Andres teaches that "when one server 120 of the service group processes the 
dispatched transaction differently than the other servers, the Arbiter uses a voting scheme 
to decide which server or servers are to be taken off-line within the service group. In the 
general case, the Arbiter uses a "majority rules" voting scheme. Under the majority rules 
scheme, if a minority number of servers 120 of the service group report a different 
outcome than the other servers, the minority servers are treated as being "inconsistent" 
with the final outcome, and are taken off-line." See Column 19, Lines 46-55. As 
interpreted by the Applicants, San Andres teaches that an Arbiter may use a voting 
scheme to decide which application servers are deemed to be consistent and take 
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application servers that are inconsistent offline for maintenance. As interpreted by the 
Applicants, the Arbiter is an arbitration mechanism and is not a group services client, 

San Andres does not teach or suggest '^voting, by any one of the other nodes in 
the computer cluster, to continue with update process if a match does not result from the 
comparison" as recited in claim 21. Instead, San Andres teaches that "when one server 
120 of the service group processes the dispatched transaction differently than the other 
servers, the Arbiter uses a voting scheme to decide which server or servers are to be 
taken off-line within the service group. In the general case, the Arbiter uses a "majority 
rules" voting scheme. Under the majority rules scheme, if a minority number of servers 
120 of the service group report a dijferent outcome than the other servers, the minority 
servers are treated as being "inconsistent'' with the final outcome, and are taken off- 
line." See Column 19, Lines 46-55. As interpreted by the Applicants, San Andres 
teaches that an Arbiter may tdse a voting scheme to decide which application servers are 
deemed to be consistent and take application servers that are inconsistent off-line for 
maintenance, San Andres does not teach voting by any of the other nodes in the 
computer cluster. Furthermore, San Andres does not teach voting by any of the other 
nodes in the computer cluster to continue with update process if a match does not result 
from the comparison 

For at least the above reasons, claims 1,9, 15 and 21 are patentable over San 
Andres. Claims 2-8, 11-14, 16-20 and 22-25 each recite combinations of features 
including the above combinations, and thus are patentable for at least the above reasons 
as well. Claims 2-8, 11-14, 16-20 and 22-25 recite additional features which, in 
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combination with the features of the claims upon which they depend, are patentable over 
San Andres. 

For example, San Andres does not teach or suggest that "the out-of-sync condition 
is an error" as recited in claim 2. Instead, San Andres teaches that "when one server 120 
of the service group processes the dispatched transaction differently than the other 
servers, the Arbiter uses a voting scheme to decide which server or servers are to be 
taken off-line within the service group." In the general case, the Arbiter uses a "majority 
rules" voting scheme. Under the majority rules scheme, if a minority number of servers 
120 of the service group report a different outcome than the other servers, the minority 
servers are treated as being "inconsistent with the final outcome, and are taken off- 
line." See Column 19, Lines 46-55. As interpreted by the Applicants, San Andres 
teaches that an Arbiter may use a voting scheme to decide which application servers are 
deemed to be consistent and take application servers that are inconsistent off-line for 
maintenance. As interpreted by the Applicants, San Andres simply teaches an Arbiter 
using a scheme to determine which servers are to be taken off-line but does not teach 
detecting an out-of-sync condition that is an error. 

San Andres does not teach or suggest that "refreshing the database in response 
to the detecting step" as recited in claim 3. Instead, San Andres teaches that "when an 
application server of a service group receives a client request that indicates a 
modification to replicated service content data, the server/service generates an update 
transaction and sends the update transaction to the Arbiter. The Arbiter records the 
update transaction in a service-group specific transaction log ... and forwards the 
transaction for immediate processing to every application server in the server group ... 
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The application servers process the update transaction, and return status codes 
indicating, for each respective application server, the 'success' or 'failure' of the 
transaction'' See Column 3, Lines 26-38. San Andres further teaches that ''when 
different application servers return different status codes, the Arbiter uses the ... conflict 
resolution feature to resolve the conflict." See Column 3, Lines 41-44. San Andres 
further teaches that the Arbiter determines the "final outcome" of the transaction for the 
group as a whole and takes inconsistent servers offline. 5ee Column 2, Lines 56-50. As 
interpreted by the Applicants, San Andres teaches an arbiter that sends an update 
transaction to each application server to be processed. Upon the application servers 
processing the update transactions, the arbiter may be configured to resolve a conflict 
where the conflict being different status codes sent by different application servers upon 
processing the update transaction. As interpreted by the Applicants, the application 
servers do not process the update transaction in response to detecting an out-ofsync 
condition. The application servers simply process the update transaction sent by the 
arbiter. 

San Andres does not teach or suggest that "resetting cluster membership in 
response to the detecting step" as recited in claim 4. Instead, San Andres teaches that 
"when one server 120 of the service group processes the dispatched transaction 
differently than the other servers, the Arbiter uses a voting scheme to decide which server 
or servers are to be taken off-line within the service group. In the general case, the 
Arbiter uses a "majority rules" voting scheme. Under the majority rules scheme, if a 
minority number of servers 120 of the service group report a different outcome than the 
other servers, the minority servers are treated as being "inconsistent" with the final 
outcome, and are taken off-Hne." See Column 19, Lines 46-55. As interpreted by the 
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Applicants, San Andres teaches that an Arbiter may use a voting scheme to decide which 
application servers are deemed to be consistent and take application servers that are 
inconsistent off-line for maintenance. As interpreted by the Applicants, San Andres 
simply teaches an Arbiter using a scheme to determine which servers are to be taken 
off-line but does not teach resetting cluster membership in response to detecting an 
out-of-sync condition. 

San Andres does not teach or suggest "declaring an end-of-transaction state on 
update voting completion when the database update is being done in a transactional 
manner" as recited in claim 6. Instead, San Andres teaches that "the servers that receive 
the update transaction from the Arbiter respond by processing the update transaction, and 
by retuming a status code that indicates the success or failure of the transaction^ See 
Column 19, Lines 25-28. As interpreted by the Applicants, San Andres teaches that the 
servers process the update transaction sent from the Arbiter and then return a status code 
that indicates whether the server was successful or not on processing the update 
transaction, San Andres does not teach that the servers declare an end-of-transaction 
state on update voting completion when the database update is being done in a 
transactional manner. 

San Andres does not teach or suggest backing out an update when update voting 
does not meet a criteria established for success'' as recited in claim 7. Instead, San 
Andres teaches that "the servers that receive the update transaction from the Arbiter 
respond by processing the update transaction, and by retuming a status code that 
indicates the success or failure of the transaction'' See Column 19, Lines 25-28. As 
interpreted by the Applicants, San Andres simply teaches that the servers process the 



-16- 




AT9-98-441 PATENT 



update transaction sent from the Arbiter and then return a status code that indicates 
whether the server was successful or not on processing the update transaction. San 
Andres does not teach that the Arbiter or server appUcation backs out an update when 
the update voting does not meet a criteria established for success. 

San Andres does not teach or suggest that "the criteria for success is that no more 
than one node has inconsistent results'' as recited in claim 8. Instead, San Andres 
teaches that "when one server 120 of the service group processes the dispatched 
transaction differently than the other servers, the Arbiter uses a voting scheme to decide 
which server or servers are to be taken off-line within the service group. In the general 
case, the Arbiter uses a "majority rules" voting scheme. Under the majority rules 
scheme, if a minority number of servers 120 of the service group report a different 
outcome than the other servers, the minority servers are treated as being "inconsistent'' 
with the final outcome, and are taken off-line." See Column 19, Lines 46-55. As 
interpreted by the Applicants, San Andres teaches that m Arbiter-vaziy use a voting 
scheme to decide which application servers are deemed to be consistent and take 
application servers that are inconsistent off-line for maintenance. San Andres does not 
teach that the Arbiter's voting criteria is that no more than one node has inconsistent 
results. Instead, as interpreted by the Applicants, the Arbiter's voting criteria is to treat 
the minority number of servers with a different outcome than the majority number of 
servers as inconsistent. 

San Andres does not teach or suggest "voting, by any one of the other nodes in 
the computer cluster, to continue with update process if a match does not result from the 
comparison" as recited in claims 10 and 26 and similarly in claim 16. Instead, San 
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Andres teaches that "when one server 120 of the service group processes the dispatched 
transaction differently than the other servers, the Arbiter uses a voting scheme to decide 
which server or servers are to be taken off-line within the service group. In the general 
case, the Arbiter uses a "majority rules" voting scheme. Under the majority rules 
scheme, if a minority number of servers 120 of the service group report a different 
outcome than the other servers, the minority servers are treated as being "inconsistent 
with the final outcome, and are taken off-line." See Column 19, Lines 46-55. As 
interpreted by the Applicants, San Andries teaches that an Arbiter may use a voting 
scheme to decide which application servers are deemed to be consistent and take 
application servers that are inconsistent off-line for maintenance. San Andres does not 
teach that voting by any of the other nodes in the computer cluster. Furthermore, San 
Andres does not teach noting by any of the other nodes in the computer cluster to 
continue with update process if a match does not result from the comparison. 

San Andres does not teach or suggest ^^broadcasting an approval of the update 
to the database if all of the other nodes vote to approve the update'' as recited in claims 
1 1 , 22 and 27 and similarly in claim 17. Instead, San Andres teaches that "each update 
transaction replicated by the transaction replication service is stored in a transaction log. 
When a new application server is brought on-line, previously-dispatched update 
transactions stored in the transaction log are dispatched in sequence to the new server 
to bring the new server's content data up-to-date." See Abstract. San Andres does not 
teach or suggest broadcasting an approval of the update to the database. Furthermore, 
San Andres does not teach or suggest broadcasting an approval of the update to the 
database if all of the other nodes vote to approve the update. Applicants kindly request 
the Examiner to particularly point out in San Andres where broadcasting an approval 
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of the update to the database and broadcasting an approval of the update to the database 
if all of the other nodes vote to approve the update is taught. 

San Andres does not teach or suggest ''if more than one of the plurality of nodes 
votes to continue, performing a recovery process" as recited in claims 12, 23 and 28 and 
similarly in claim 18. Instead, San Andres teaches that "when one server 120 of the 
service group processes the dispatched transaction differently than the other servers, the 
Arbiter uses a voting scheme to decide which server or servers are to be taken off-line 
within the service group. In the general case, the Arbiter uses a "majority rules" voting 
scheme. Under the majority rules scheme, if a minority number of servers 120 of the 
service group report a different outcome than the other servers, the minority servers are 
treated as being ''inconsistent" with the final outcome, and are taken off-line." See 
Column 1 9, Lines 46-55 . As interpreted by the Applicants, San Andres teaches that an 
Arbiter may use a voting scheme to decide which application servers are deemed to be 
consistent and take application servers that are inconsistent off-line for maintenance. 
As stated above, San Andres does not teach voting by nodes. Thus, necessarily, San 
Andres does not teach if more than one of the plurality of nodes votes to continue^ 
performing a recovery process. 

San Andres does not teach or suggest 'Hfmore than a specified number of the 
nodes vote to continue^ backing out the update to the database as recited in claim 13, 24 
and 29 and similarly in claim 1 9. Instead, San Andres teaches that "when one server 1 20 
of the service group processes the dispatched transaction differently than the other 
servers, the Arbiter uses a voting scheme to decide which server or servers are to be 
taken off-line within the service group. In the general case, the Arbiter uses a "majority 
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rules" voting scheme. Under the majority rules scheme, if a minority number of servers 
120 of the service group report a different outcome than the other servers, the minority 
servers are treated as being "inconsistent'' with the final outcome, and are taken off- 
line." See Column 19, Lines 46-55. As interpreted by the Applicants, San Andres 
teaches that an Arbiter may use a voting scheme to decide which application servers are 
deemed to be consistent and take application servers that are inconsistent off-line for 
maintenance. As stated above, San Andres does not teach voting by nodes. Necessarily, 
San Andres does not teach if more than a specified number of the nodes vote to continue 
backing out the update to the database. 

San Andres does not teach or suggest ''if less than a specified number of the 
nodes voted to continue, performing the recovery process on the specified number of the 
nodes" as recited in claims 14, 25 and 30 and similarly in claim 20. Instead, San Andres 
teaches that "when one server 120 of the service group processes the dispatched 
transaction differently than the other servers, the Arbiter uses a voting scheme to decide 
which server or servers are to be taken off-line within the service group. In the general 
case, the Arbiter uses a "majority rules" voting scheme. Under the majority rules 
scheme, if a minority number of servers 120 of the service group report a different 
outcome than the other servers, the minority servers are treated as being "inconsistent" 
with the final outcome, and are taken off-line." See Column 19, Lines 46-55. As 
interpreted by the Applicants, San Andres teaches that an Arbiter may use a voting 
scheme to decide which application servers are deemed to be consistent and take 
application servers that are inconsistent offline for maintenance. As stated above, San 
Andres does not teach voting by nodes. Necessarily, San Andres does not teach if less 
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than a specified number of the nodes voted to continue, performing the recovery process 
on the specified number of the nodes. 

As a result of the foregoing, Applicants respectfully assert that the Examiner's 
prima facie case of obviousness is not taught or suggested by the cited prior art since 
there are numerous claim limitations, and thus one skilled in the art would not have been 
able to create the claimed invention in view of the cited prior art. 
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n. CONCLUSION 

As a result of the foregoing, it is asserted by Applicants that the remaining Claims 
in the Application are in condition for allowance, and respectfully request an early 
allowance of such Claims. 

Applicants respectfully request that the Examiner call Applicants' attorney at the 
below listed number if the Examiner believes that such a discussion would be helpful in 
resolving any remaining problems. 



5400 Renaissance Tower 
1201 Elm Street 
Dallas, Texas 75270-2199 
(512)370-2832 
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